🟡 Heimdall Review Status

Ran a no-payment external pass against the public Jorkal surface. No payment headers or paid calls were sent.

Repro:

npx --yes x402-surface-check@latest https://vercel-deploy-alpha-puce.vercel.app/openapi.json --limit 8 --origin https://vercel-deploy-alpha-puce.vercel.app
curl -i https://vercel-deploy-alpha-puce.vercel.app/.well-known/x402
curl -i -X OPTIONS https://vercel-deploy-alpha-puce.vercel.app/floor/degods \
  -H "Origin: https://vercel-deploy-alpha-puce.vercel.app" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: x-payment,content-type,authorization"

What looks good:

• /.well-known/x402, /openapi.json, and /llms.txt are public and machine-readable.
• All 8 sampled OpenAPI GET routes returned structured 402 challenges before execution.
• Browser preflight returns 204 with Access-Control-Allow-Origin: *, Access-Control-Allow-Methods: GET, OPTIONS, and Access-Control-Allow-Headers: x-payment, content-type, authorization.
• Observed challenge prices match the docs range ($0.001 to $0.010) and the live rail is Base mainnet USDC (eip155:8453, 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913).
• The challenge top-level resource.url matched the charged URL in the sampled routes.

Patch notes before/after merge:

• P2: the paid 402 responses currently send Cache-Control: public, max-age=0, must-revalidate. For payment challenges, I would switch these to no-store/private or otherwise bypass shared caches so a challenge cannot be replayed from an intermediary cache boundary.
• P2: the accepts[] entries do not repeat the canonical resource URL. The top-level resource.url is present, but mirroring the charged URL into each accept leg or documenting the top-level field as the authoritative binding makes wallet spend maps/replay checks easier.
• P3: the OpenAPI paths are concrete examples such as /floor/degods while also declaring path parameters like symbol. If the intent is arbitrary collection symbols/wallets, templated paths such as /floor/{symbol} and /wallet/{address}/nfts will work better for client generators.

I did not send X-PAYMENT, sign any request, or attempt a paid call.

Thanks for the thorough audit @TateLyman! All three points have been addressed in the latest deployment:

P2 — Cache-Control on 402 responses: Changed from public, max-age=0, must-revalidate to Cache-Control: no-store, private so payment challenges cannot be served from intermediary caches.

P2 — Resource URL in accepts[]: Added resource: url to each entry in the accepts array, mirroring the top-level resource.url binding into each accept leg to make wallet spend maps and replay checks unambiguous.

P3 — OpenAPI path templates: All 8 paths in /openapi.json now use proper templates (/floor/{symbol}, /listings/{symbol}, /stats/{symbol}, /activity/{symbol}, /token/{mint}, /wallet/{address}/nfts, /wallet/{address}/activity, /wallet/{address}/value) instead of concrete examples. The x-guidance field and parameter schemas remain for LLM context.

All changes are live at https://vercel-deploy-alpha-puce.vercel.app — happy to re-run the surface check if helpful.

Re-ran the no-payment pass on the updated deployment. I did not send payment headers, sign requests, or attempt paid calls.

Repro:

npx --yes x402-surface-check@latest https://vercel-deploy-alpha-puce.vercel.app/openapi.json \
  --limit 8 \
  --origin https://vercel-deploy-alpha-puce.vercel.app

curl -i https://vercel-deploy-alpha-puce.vercel.app/floor/degods \
  -H "Origin: https://vercel-deploy-alpha-puce.vercel.app"

curl -i -X OPTIONS https://vercel-deploy-alpha-puce.vercel.app/floor/degods \
  -H "Origin: https://vercel-deploy-alpha-puce.vercel.app" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: x-payment,content-type,authorization"

Confirmed fixed:

• All 8 sampled OpenAPI routes still return structured 402 challenges before execution.
• The 402 responses now return Cache-Control: no-store, private.
• accepts[] now includes the concrete resource URL binding.
• OpenAPI paths are now templated (/floor/{symbol}, /wallet/{address}/value, etc.).

One browser-agent item still remains: the 402 challenge is only in the payment-required response header, but the 402 response does not include Access-Control-Expose-Headers: payment-required (or a broader expose list). Preflight succeeds, but browser JS still cannot read the payment challenge header after the 402. That is the only launch-readiness issue I still see from this public no-payment pass.